Hi @mrtergl!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

This improvement can solve issue #2471

I think this pull request is useful.

I am currently using Prophet for various purposes.
One of them is to predict traffic trends/detect anomalies.

I currently use it as a code to replace negative values ​​with 0 in the post-processing process.

Because even if I do not train Prophet with values ​​less than 0, there were cases where the prediction result was predicted as a negative number less than 0.

So I personally think this suggestion can be useful.

Hi @mrtergl!

Thanks for your contribution! I also agree that this is a fairly simple feature that gets often asked, so why not implement it.
While reviewing the code I got one question. I am quite new to forecasting and even programming in Python, so please forgive me if the answer is obvious.

It seems that on line 1460 in file python/prophet/forecaster.py you clip all seasonality components' values to zero. Is it correct to do that? The effect of seasonality may be negative even if predicted y cannot be below zero, for example, sales of winter products cannot go negative but seasonality for summer months can.

Thanks in advance for your reply!

Hi @HumptyHans,
Thank you for noticing, you are right about seasonality values being able to go below zero. I removed the part and tested it.

Hey @mrtergl,
Thanks for making changes! But without seasonality clipping, the resulting value can still go below zero.
Something needs to be done with 'additive_terms'. The easiest suggestion is to ensure that if it is negative, its absolute value doesn't exceed the trend value.
I’m just not sure if it’s the correct approach from a statistical perspective.

Hi @HumptyHans ,

I'm not sure I understand you well because of my lack of knowledge in the statistical area. From what I understood, seasonality values such as 'additive_terms' can be negative while the prediction stays positive. I made some refactoring on the code and I hope I got the right result for all cases without negative predictions.

With all seasonalities included, here is the result you will get if you set negative_prediction_values to false.

As you can see seasonalities have both negative and positive values while prediction has always been positive

@tcuongd Could you please check my pull request?

Hey @mrtergl
I see that your last commit fixes exactly what I meant. Basically, the whole PR could have been reduced to these two lines:

if not self.negative_prediction_values:
    df2['yhat'] = df2['yhat'].clip(lower=0)

Hi @HumptyHans ,

We should be able to make trend, yhat upper and yhat lower predictions positive while the flag negative_prediction_values is set to false. So the code you provided will be insufficient.

But I removed the part where I clipped seasonalities' lower and upper values. So that, all seasonality predictions (including upper and lower values) can be negative even if the metric is non-negative (such as count, latency).